COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X interface  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  07:47:17 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 10:46-EST
Date: Thu, 29 Jan 87 10:48 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X interface
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129104842.9.RWS@KILLINGTON.LCS.MIT.EDU>

The C Xlib was designed without any thought given to multiple execution
threads.  I hope a Lisp interface will be designed with concurrency in
mind (but without requiring multiple threads); I would hate to see two
different interfaces evolve.

Just as one example, note that X has asynchronous errors; will the
interface undertake to dispatch errors back to the appropriate thread?

In the Unix world one is almost forced to think of IPC as the only link
to an X server (console).  In a lispm world (which is what we all
desire, right? :-) , it is natural to assume that (eventually) the most
commonly accessed X server will be just another collection of objects
and threads in your address space.  One would like clients to have
direct access to the server objects, without imposing a (shared-memory)
channel between the client and some server thread.  This certainly has
implications for the structure of the server, but it would seem to
affect the structure of a programming interface as well.  For example,
will you want local clients to pay the overhead of the resource-id to
server-object translation, or of packet formatting?  If you believe the
local case should be have more "direct" links, then it would seem you
want the programming interface to present some sort of (object)
abstraction to resources, since resource ids alone won't be the only
coin for communication.

However, there are some problems with defining an interface in terms of
anything but resource ids.  (These same problems came up in early C Xlib
discussions, which is why Xlib looks the way it does.)  Resource id
transmission is not a one way street; there are various ways in which
the server can hand them back to you.  For example, device events are
reported not only with the "event" window id but also with a child
window id.  If you try to hide resource ids from the application, then
any ids coming back from the server should also be hidden, which means
you need a reverse mapping.  How is this mapping maintained?  How is it
garbage collected?  If the application-level manifestation of the
resource has embedded state, how do you decide which thread's or
activity's manifestation to reverse map to?

This in part depends on your point of view about how event dispatching
should work.  Is there a single event queue that threads pull things off
of, or are events automatically dispatched to per-window or per-thread
queues, or does each window have associated with it a "call-back"
function for each event type (and what thread is that function called
within?)

∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Me 'n X (ignore if you like)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  06:31:12 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:30-EST
Date: Thu, 29 Jan 87 09:32 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Me 'n X (ignore if you like)
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129093237.6.RWS@KILLINGTON.LCS.MIT.EDU>
Comment: Remailed at SU-AI after delay caused by mailing list error.

    From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
    My understanding is that you are implementing X11 on a lisp machine ...

Just to set the record straight, I am engaged (as time permits) in building
a Version 11 server in (extended) CL, initially targeted at running on Symbolics
and TI lispms executing inside one of their system's windows.  I have also
been experimenting with slipping X in under the covers of the existing Symbolics
window system, so that "native" applications can be used across a network
without any application modifications.  I am NOT engaged in building a programming
interface to X.

    From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
    I would like to know what you (specifically) and others want to see ...

There are about 37 other aspects of X (plus my "real" research) keeping me busy;
I don't have the time to design a Lisp interface (but I would like to stay tuned
in and offer my two cents when I can), and I believe there are people out there
who can do a better job of it than me anyway.